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This is Module 10: 
Writing Advanced Programs 


This is the final module in your Contemporary Programming and Software 
Design Series. In this module, you will examine a number of features that 
distinguish advanced, high-quality programs from ordinary or even sub- 
standard programs. 


Some of the concepts you will explore in this module are: 
* User-Friendly software 
* More on Structured Programming 
* Visual displays, sound effects, and artificial speech 
* Practical algorithms for number crunching 
* Artificial Intelligence 
* Optimizing your programs 


In addition, we have included a number of programs on your Program Disk 
for this module. Except for the initial welcome and title programs, these are 
either Shareware or in the public domain, so you can freely share them with 
others if you wish. We believe that you will find these programs interesting 
and possibly helpful both in using your computer and in developing new programs 
of your own. 


When you have completed this module, you will have completed your 
Contemporary Programming and Software Design Series. However, this does not 
mean the end of your excursion into the world of programming. You now have 
the knowledge and understanding to design and develop your own programs, 
according to your own applications and requirements. It is our hope that you 
will continue to work with your computer, and continue to develop your skills 
in computer programming. 


Best wishes to you! 
Sincerely, 2 
Kenneth J. Bigelow 
Project Engineer 
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CONTEMPORARY 
PROGRAMMING 
AND SOFTWARE 
DESIGN SERIES 


Welcome to Module 10 of your Contemporary 
Programming and Software Design Series. In this 
module, you will complete your study of the 
programming process with a look at modern 
programming techniques and concepts. These are 
concepts that have developed over the years as 
professional programmers worked to solve prob- 
lems that existed in earlier programming languages. 

You have already seen a number of these ideas in 
operation. For example, the concept of structured 
programming developed gradually, as programmers 
found their early programs becoming difficult to 
work with and unwieldy in operation. 

In addition, programmers developed a number of 
techniques for faster program development, faster 
program execution, and program design techniques 
that simplify the debugging process. This permitted 
them to develop programs that simulated intelligent 
behavior within their own limits. Indeed, Artificial 
Intelligence is a new, expanding field in program 
design and development. 

In Module 9, you learned a number of the tools 
and tricks used by programmers to make their work 
easier. Now, we will explore some additional tools 
and tricks, and the methods by which more 
advanced programs are designed and developed. 

As with the demonstration programs on all of 
your previous program disks, those on the disk 
enclosed with this module are copyrighted by the 
McGraw-Hill Continuing Education Center. You 
may make as many backup copies as you may need 
for your own use (in fact we urge you to do so), but 
you may not sell or give away copies of these 
programs. 
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However, the remaining programs on your disk 
are either Shareware or in the public domain. You 
may distribute these in accordance with the docu- 
mentation provided with them. 

As soon as you are ready to begin this module, 
turn on your computer and peripheral equipment, 
insert your Program Disk into Drive 8, and type: 


LOAD’WELCOME?",8<return> 
RUN<return> 


Turn to the Introduction in your Learning Guide 
when your computer directs you to do so. 
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WRITING ADVANCED PROGRAMS 


As with all disciplines and fields of endeavor, 
program design and development did not appear all 
of a sudden in its final form. Indeed, the field of 
programming is still developing and will continue to 
do so for a long time yet to come. 

The original digital computers were physically 
very large, expensive, and very limited in capacity. 
The first electronic computers in fact used massed 
banks of vacuum tubes as the active elements. Rhey 
required more power for cooling and for running the 
filaments than everything else put together, and 
used miles upon miles of wire for interconnections. 
They had extremely limited capabilities and pro- 
cessed data very slowly. 

With the advent of transistors and then inte- 
grated circuits, computers became smaller and 
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faster, and had more capabilities built into them. 
They also required far less power to operate. 
Large-scale integration (LSI and VLSI) have con- 
tinued this trend. 

Programming techniques and requirements have 
evolved along with the computers. Early program- 
ming languages were very clumsy and were defi- 
nitely designed specifically for the machine that used 
them. It took a long time for a programmer to learn 
all of the requirements of a particular computer and 
programming language. 

With the development of improved computers 
came the development of better, more general 
programming languages. In fact, the hardware 
design of many computers and central processing 
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units took more and more programming require- 
ments into account. As a result, many modern 
high-level languages appear the same to the user 
regardless of the actual computer used, within the 
display and input capabilities of the computer itself. 

One of the first languages to accomplish this feat 
was VisiCalc™, a spreadsheet program. As an early 
spreadsheet generator, it had its limitations, but it 
was, nevertheless, quite powerful and useful in its 
day. Versions of VisiCalc were produced for the 
TRS-80 Model I, II, and 4, as well as for the Apple II 
and the IBM PC. For each computer, the data for 
any one spreadsheet could be readily saved on disk. 
Although the disk formats were different, so that 
one computer could not read the data from a disk 
formatted on a different type of computer, the data 
could be transmitted from one computer to another 
via communications link, and could be used directly 
to recreate the same spreadsheet on the different 
computer. 

FORTH is another language which has been 
made portable from computer to computer. In 
FORTH, only a very few words need to be written in 
machine code. Once this small core, which deals 
mainly with input and output, has been written for a 
given type of computer, the rest of the dictionary is 
installed as compiled, high-level FORTH. From then 
on, new words can be added at any time and can be 
transported from computer tocomputer as 
“screens,” which are ASCII text files that can be 
read by almost any computer anywhere. 

As computers and programming languages have 
improved and developed, so have programming 


techniques. Early programs were written for use by 
programmers, who were assumed to already un- 
derstand the inner workings of the machine. In- 
structions to the program were documented (if at 
all) in terms of machine operations. No indication 
was given by the program of what instructions it 
would accept at any particular time, or what its 
numerical error messages might mean. 

Since then, programs have gradually become 
more user-friendly, with menus and meaningful 
error messages, as well as more informative 
prompts and some effort to allow for inexperienced 
users. 

The development of modern, sophisticated pro- 
grams involves a number of different considera- 
tions, and is still evolving as advances are made in 
the computer field. In this module, we will explore 
these concepts and considerations, and determine 
what is required for the development of modern, 
advanced programs. 
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TRACK 1 


THE USER-FRIENDLY CONCEPT 


Early computer programs made no effort whatever 
to help the user during program operation. The 
NRIBUG program you received in an earlier module 
is an example of this. Once you load and execute 
NRIBUG, it issues its “.” prompt and waits for your 
input. If you don’t already know the valid NRIBUG 
commands, you have to hunt them down in the 
documentation and figure out for yorself just how to 
use them. NRIBUG itself offers no help or infor- 
mation in any form. 


In a similar vein, early text editor programs were 
designed and intended to be used for creating and 
modifying assembly-language source files. They 
were known as “Line Editors” because they oper- 
ated on the text file on a line-by-line basis. To list or 
modify a particular line, you had to use commands 
to move the edit pointer up or down a specific 
number of lines, or to search for specific text. You 
could not move the cursor around on the screen, 
and again error messages were uninformative. For a 
list of commands and command syntax, or for the 
meaning of an error message, you would have to 
refer to the user’s manual and look it up. 
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This sort of approachis considered to be 
“unfriendly.” It assumes that the user already knows 
how to use the program. It is, however, the easiest 
way to write the program, since the programmer 
needs only to be concerned with the actual func- 
tioning of the program. 

Unfortunately, even experienced programmers 
found that by the time they learned how to use such 
a program, their copies of the User’s Guide had 
become dog-eared and dirty with all the handling 
required to look up instruction syntaxes and error 
messages. Even though only programmers had any 
real access to computers, it was clearly a problem. 
There had to be a better way! 

This need became more obvious as computers 
became smaller, cheaper, and more powerful. Now 
that almost anyone can own a personal computer at 
very low cost, it is necessary that programs for 
general use not require a skilled programmer to 
operate them. Programs for general use are devel- 
oped to be sold to computer users, and very few 
people will buy a program that they cannot use 
readily. This kind of demand caused the evolution of 


Writing Advanced Programs 


Track 1 


programs that were “friendly” to the user. These are 
the “user-friendly” programs. 


Sector 1: Verbal Error Messages 


One of the first things that was done to make 
programs more friendly was to include clear error 
messages. One early technique, still used in some 
programs, was to point out the exact location of 
what the program could not understand. This was 
done originally by dropping down to the next display 
line and outputting a message such as “Error” at 
the appropriate location. 

This was only a little bit helpful, as it did not 
indicate just what the program disliked about the 
user input. It was necessary to go back to the 
manual to look up the correct syntax of the 
instruction and then figure out what was wrong with 
the rejected input line. 

The next step was error messages such as 
BASIC reports in case of a problem. Messages such 
as “Syntax Error in Line nnnn” not only tell where to 
look for the error, but give some information 
regarding the nature of the error. However, the user 
must still determine exactly what BASIC did not like 
within the line before correcting the problem. 

Combining these techniques came next. For 
example, many FORTH systems are or can be 
configured to repeat the specific word that caused a 
problem and then give an error message. The result 
might look like this: 


FORTH? Not in Dictionary 


or: 
ENDIF? Misnested Conditionals 


If FORTH is interpreting from a screen, it also 
points out the location of the error within the screen 
for more rapid identification. 

It is not necessary to display paragraphs of 
information in response to an error. However, a 
clear, concise, and complete error message is far 
more meaningful to the user than a bald “Error 
#241.” 


Sector 2: Correct Usage Reminder 


One very effective approach which has recently 
caught on is to respond to incorrect usage with a 
screenful of information showing the correct usage. 
Earlier error messages consisted of a bald statement 
such as: 

Illegal number of parameters 


or: 


Invalid parameters 
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This sort of message is not very helpful, although 
it can be placed into the program easily and quickly. 
However, a character string showing the correct 
usage, such as is incorporated into the PDSW 
program from your previous module, is not much 
more difficult to include in the program. 


Sector 3: The Use of Menus 


Of course, the User’s Guide is still the place to turn 
to, in order to get detailed information on program 
operation and requirements. However, the program 
itself can readily include visual “guides” to remind 
the user of pertinent information regarding what the 
program is now doing and what options are cur- 
rently open to the user. Such a list of choices is 
called menu, and it is quite possible and practical for 
a program to go through several levels of menus as 
the user selects the desired function and parame- 
ters. 

Of course, it is possible to overdo it with menus. 
This is especially true for the experienced user, who 
may wish to bypass at least most of the menus. Such 
a user will be held back by too many menus that 
constantly appear. 

The solution to this is to start the program with a 
primary menu. For example, a word processing 
program might start with a file-handling menu that 
allows the user to load or save a text file, clear the 
text edit buffer, begin editing, or go to a different 
menu if desired. 

An auxiliary menu might be the PRINT menu, 
from which the user might directly print out a file, or 
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first go to a third-level menu to preset various 
parameters involved with printing. These would 
include margins, line spacing, partial printing, 
number of copies, etc. 

The point is that menus should be helpful without 
being obtrusive. Each menu should list the available 
choices, with a brief (two to three word) identifica- 
tion of each choice. Extra help with the choices 
should be either in the User’s Guide only or else 
provided as one of the menu options. In that way, 
the extra help is available but can be ignored if it is 
not needed. The same pattern can be followed for 
subsidiary menus. 

A variation of this technique is the method used 
by WordStar™ to display its help lists. This program 
allows the user to select any of four levels of help, 
where full help constantly displays, across the top of 
the screen, the current menu of control functions 
available and the methods required to obtain other 
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menus. The next level down does not display the 
main menu, and will accept control code sequences 
directly. However, if the user delays or hesitates 
before completing the control sequence, the menu 
will appear in case it is required. 

Lower levels of help omit the primary menu, and 
then all menus. The user can preselect the desired 
help level during installation or re-installation, and 
can change it at any time while using the program. 

A similar approach is to place such a menu on the 
screen at the touch of a key, and then remove it 
when the key is pressed again. 

It is desirable to be able to remove or bypass the 
menu when it is no longer needed. The new user will 
often refer to the menu to help remember various 
functions. However, the menu does take up valu- 
able display space, so it is in the way when it is no 
longer needed. 


Sector 4: Help Files 


An alternative to built-in menus invoves the use of a 
separate text file on disk to provide on-line help 
when needed. There are several ways to implement 
this approach. 

The simplest method is to go through the entire 
HELP file each time it is requested. Then the user 
can scan the file for the specific assistance or 
information needed, and scan out to the end, thus 
returning to the main program. The problem with 
this is that the user must go through the entire file in 
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order to get help on a paticular subject. If the HELP 
file is large, this becomes a real problem. 

Another approach is to use special character 
sequences to help the program index its way 
through the HELP file to find information on specific 
topics. For example, dBASE II™ has a companion 
HELP file called DBASEMSG.TXT. Each topic is 
identified by its name, preceded by an asterisk (*). 
Thus, if you want help with the APPEND command, 
simply type in the command line: 


HELP APPEND(return) 


DBASE will search the file for the sequence 
*APPEND and will proceed to display the suc- 
ceeding text to the screen, until it reaches the 
character sequence *EXIT, at which point the 
command prompt will be placed on the screen and 
dBASE will again wait for your input. 

In either case, the HELP file may be expanded at 
any time, without modifications to the original 
program. 

The advantage of using an indexed HELP file is 
that the user will see only information related to the 
specific topic of interest at the moment. This 
eliminates the need for scanning through a lot of 
unrelated information and can save large amounts 
of time. It also means that very large HELP files can 
be used, with detailed information for each topic 
(DBASEMSG.TXT runs close to 50K bytes and 
includes detailed information on almost every 
dBASE command.). 

The disadvantage of the indexed HELP file is that 
the routine scanning must be more complex than if 
it just dumped the entire file to the screen. However, 
the enhanced usefulness of the file generally makes 
it well worth while to do this. 
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Sector 5: A Command/Status Line 


Another possibility is to incorporate one or more 
”“command/ status lines” inthe program. For 
example, most spreadsheet programs, starting with 
VisiCalc™ and continuing through Lotus 1-2-3™, use 
the top two or three lines of the display to display the 
current status information and to list the available 
commands when the command key is pressed. 


In 1-2-3, the upper left-hand corner shows the 
current cell where the cursor is located. The upper 
right corner shows either WAIT, ERROR, or 
READY according to what the program is doing at 
the moment. The bottom line displays the current 
date and time, as well as the status of such program 
modes as INSERT and CAPS LOCK. It also shows 
the general operating status of the program. 

The second line from the top displays the current 
command choices, while the third line displays the 
subcommands available under the currently se- 
lected command. The user may use cursor keys to 
select the desired command, or else select the 
desired command by typing its first letter. At that 
point, the list of subcommands moves up to the 
second line, and any third-level options available are 
listed on the third line. If the second line shows the 
actual operation, the third line shows a brief 
description of that operation. 

This technique allows the novice user to see the 
available subcommands and options as a guide in 
selecting the desired command, but also allows the 


MODULE 10 


experienced user to directly select the desired 
command and option with just a few keystrokes. 

The whole idea of “User-Friendly” programs is 
that they should be easy to use, even by nonpro- 
grammers. This means that the program should 
incorporate guides and assistance for the new user, 
but not overload the experienced user with exces- 
sive command procedures. Even very sophisticated 
programs can be made easy and pleasant to use. 

A true, user-friendly program will require little or 
no preliminary instructions for the new user. 
Advanced features may require additional instruc- 
tion, after the user becomes familiar with and 
comfortable with the operation of the basic program 
features. This allows the user to “grow into ” the 
program, instead of having to learn the entire 
command set all at once. 


— 


~ 
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TRACK 2 


STRUCTURED PROGRAMMING REVISITED 


We discussed structured programming in Module 9, 
and we touched on it in previous modules as well. 
But, as your programs become more and more 
advanced, it also becomes much more important 
that they be logically structured. 

The reason for this is that any large program 
contains many different functional modules or 
logical units. Each subroutine is a single unit in this 
sense, even if it calls other subroutines. In addition, 
the main program may consist of one or more logical 
blocks. If you maintain a structured format for your 
program, you will find that all phases of program 
design and maintenance will be simplified. An 
unstructured program will be very difficult to 
troubleshoot and maintain, simply because it is 
much harder to understand and follow. 

Accordingly, let’s take another look at the 
requirements of structured programming 


Sector 1: Modular Program Structure 


A primary characteristic of a structured program is 
that each logical task or operation is performed by a 
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single, coherent block of program code. Subroutine 
calls are still perfectly satisfactory, since the com- 
puter will return directly to the point where it left the 
block. Thus, the subroutine effectively becomes 
part of the logical block when called by that block. If 
a subroutine is called more than once, it effectively 
appears that many times as a part of the block. 

Each program block or module should have only 
one entry point and only one exit point. Decisions 
and multiple program paths within the module are 
acceptable, but they must converge again to a single 
exit. Within a single module or block of code, the 
individual instructions should be executed in order, 
as far as possible. Subroutine calls are legitimate, as 
is conditional execution of a series of instructions. In 
such a case, the subroutine or series of conditional 
instructions will constitute a separate module by 
itself, also having one entrance and one exit. 

In the case of alternate conditionals or any sort of 
CASE structure, each conditional sequence is a 
coherent module or block of code, and the sur- 
rounding module determines which internal module 
to execute. 
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The use of this modular approach simplifies the 
entire programming process over a nonmodular 
approach. A single program module is relatively 
easy to design, map, and code. Once coded, it is 
easy to test and debug. Then updates and mainte- 
nance can readily be applied to the module. Finally, 
a single program module can be quickly and easily 
documented. Changes to the documentation can be 
made without having to change the entire docu- 
ment, but only those options dealing with the 
modified modules. This means updating document 
pages, rather than entire documents. 


Sector 2: A Common Method of Passing Data 


Very often it will be necessary for you to pass data 
back and forth between the main routine and a 
subroutine. The nature and amount of data will 
depend on the purpose of the subroutine. Large 
amounts of data must be passed in memory, while 
small amounts of data may be passed in registers. 
The Commodore kernal routines provide a good 
example of passing data in the CPU registers. Each 
call to the kernal is a subroutine call, except that the 
operating system supplies the subroutine. In these 
system calls, different CPU registers contain spe- 
cific information regarding the action to be per- 
formed. Thus, if an address must be passed to the 
subroutine, it is contained in X and Y, with Y holding 
the high-order half. The accumulator is also used, 
although not all routines require all three registers. 
The point here is that each register is used, as 
much as possible, for the same purpose during all 
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system calls. Thus, addresses are always passed in 
X and Y as described above. Any error or status 
code will be returned in A. 

If the subroutine needs more data than can be 
passed in the CPU registers, then it must reside 
somewhere in memory. In that case, you should 
have a fixed procedure for telling the subroutine 
where to find its data. This may mean using the DOS 
technique of using CPU registers to pass the 
address of the data, or it may mean pushing data 
onto the stack, where the subroutine will automat- 
ically assume the data to be. 

If you don’t care for either of these methods, by all 
means develop your own technique. However, once 
you have a method that you like, be sure to use it 
consistently. That way, all of your subroutines will 
look for data in the same way and will return their 
results in the same way. If you write your programs 
and subroutines in this consistent fashion, you will 
be able to see at a glance that a particular subroutine 
must contain an error because it doesn’t follow the 
pattern. Furthermore, you will be less likely to make 
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errors, because the pattern and structure of the 
subroutines will already be defined. 


Sector 3: Organizing Your Program 


Even with a modular program design and a struc- 
tured layout for each module, it is still necessary to 
carry out an additional level of organization: the 
overall program must be an organized whole. This 
will allow you to quickly and easily locate any 
particular functional module within the program. 

Early high-level language compilers made no 
effort to impose any particular organization or 
structure to a program; it was enough that the 
program worked at all. Assemblers cannot force any 
particular structure on programs, since they must 
be able to handle any instructions in any desired 
sequence. 

Newer compilers, however, do require a prede- 
fined program structure and organization. The 
required organization falls into one of two general 
categories: bottom up or top down. 

PASCAL, for example, must be coded in a 
bottom-up format. That is, the most basic, bottom- 
level subroutines must be coded first, using only 
definitions included in PASCAL. Then, the next 
level of subroutines can be keyed in. The main 
program is the last item coded, and will appear at 
the very end of the compiled program. 

FORTH is structured in the same way. You can 
add a new word to the dictionary at any time, but it 
must be defined entirely in terms of existing words in 
the dictionary. Thus, you must define your prelimi- 
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nary words (subroutines) first, and then, as the last 
new word, define your outer applications word. 

On the other hand, C compilers operate in a 
top-down format. That is, the main routine is defined 
first, and in fact must normally be called “main().” 
Then, successive levels of subroutines are defined in 
turn. In the compiled program, the main routine 
comes first, followed by the various subroutines. 

The requirement of bottom-up programming, as 
in PASCAL and FORTH, simplifies the design and 
operation of the compiler. This is because this 
structure forbids “forward references.” That is, any 
routine must be totally defined before it can be used. 
Therefore, the compiler only needs to remember 
the address of each named routine; it need not go 
back and fill in destination addresses at a later time. 

On the other hand, the top-down approach used 
by C is much closer to the normal program design 
procedure. After all, when you design your own 
program, you will normally start with the main 
routine and then design appropriate subroutines to 
perform required functions. Thus, C is structured 
more nearly like the normal design procedure than 
is PASCAL and is therefore generally considered to 
be easier to learn and use. 

When writing an assembly-language program, 
you can use either method and still have a struc- 
tured program. However, in assembly language 
there are a few other requirements to take into 
account. By doing so, you will produce a more 
coherent program than you would otherwise have. 

First, allocate all of your data storage space in one 
place. This might be at the beginning or end of the 
program, or separate from the program depending 
on your requirements. By consolidating all of your 
variable data in one place, you can quickly locate 
and check your data at any time. 

Second, put all of your constant data in one place 
in the program. This comprises data such as 
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character strings, constant powers of 10, and any 
other data that will never change while the program 
is executing. Constant data may go at either end of 
the program or, if appropriate, buried somewhere 
inside the program. However, as with variable data, 
it is preferable to have your constant data all in one 
place, so it may be checked and debugged easily, if 


necessary. 

Third, use the system resources whenever pos- 
sible. The kernal and BASIC ROMs have a wide 
range of capabilities built into them, and the kernal 
ROM especially is designed to handle many different 
kinds of operations, even though many different 
versions of the ROMs have already been used, and 
further updates are to be expected at any time. The 
code in the ROMs is carefully designed to bridge any 
variations, so that the same system call will produce 
the same result, regardless of ROM version or any 
hardware variations. 

Use the system calls for all I/O operations, 
including keyboard input and screen output. If you 
write a program that must use the RS-232 port at 
high speed, you may need to bypass the kernal 
ROM to maintain the pace. However, in any case 
where timing requirements are not this stringent, 
use the system routines provided. This will help to 
maintain full compatibility through different versions 
of Commodore computers. 
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Sector 4: Structured Documentation 


As you already know, documentation is a very 
important part of the programming process. It is just 
as important that your documentation be struc- 
tured and logically arranged as it is that your 
program be structured. 

Your User’s Manual for any program should be 
logically organized and clearly written, as well as 
complete but concise. User Friendly programs are 
nice, and are very helpful to the user. However, it is 
not reasonable to put the entire documentation for 
a program in menus and help files. The User’s 
Manual must provide the details of program oper- 
ation and an explanation of any and all special 
features included in the program. 

All manuals (User, Technical, Listings, and any 
supporting documentation) should be logically or- 
ganized, so that a functional topic can be readily 
located through the Table of Contents. Each 
document should also have an alphabetical Index, 
so that a particular command or subject may be 
directly located from its name. 

Perhaps the most effective way to design your 
documentation is to consider just how you would 
like to see the documentation for some other 
program, doing the same job as yours, but as yet 
totally unfamiliar to you. Write your documentation 
so that you would approve of it if you were using it to 
learn how to use this program. Then it is likely that 
others will be able to use it to learn the operation of 
your program. 
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DEVELOPING VISUAL DISPLAYS AND 


SOUND EFFECTS 


The visual displays used by a program can either 
enhance or detract from its perceived value. This 
does not mean that you should spend an excessive 
amount of time on the displays produced by your 
program, but you should make sure that your 
displays are correct and that they properly go with 
the program itself. 


Sector 1: A Picture is Worth 1000 Words 


Visual displays generated by your program can add 
great value to the program. Many concepts and 
activities can be presented far more effectively in the 
form of pictures than in words. In fact, large 
amounts of text are hard to read on the screen, and 
are better suited to an accompanying manual. 

Indeed, this is one of the main reasons for 
combining demonstration programs with a Learning 
Guide in this Series: text material is printed on 
paper, while some pictorial descriptions are gener- 
ated, possibly with motion, on the computer. 


MODULE 10 


A visual display generated by your program can 
be useful in many different ways, depending on the 
requirements of the program and the situation. For 
example: 


@ It can demonstrate the meaning of an instruc- 
tion or question. 

® It can list valid options or commands. 

@ It can illustrate the “standard” or default format 
expected by the program. 

® It can call attention to key concepts 

@ It can signal for urgently-needed responses. 


In these and many other ways, visual displays can 
be used to advantage by a program. 


Sector 2: Keeping the Display Appropriate 


Regardless of the nature of your program, the visual 
displays produced by it should always be appropri- 
ate to the program itself. For the most part, this 
means eliminating things from the display. 
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For example, you might have a display design 
program that will enable you to rapidly and easily 
draw displays, color them, and even provide motion. 
You might enjoy drawing cartoon characters and 
producing such displays. If so, this is perfectly all 
right, and, indeed, we wish you all the best with it. 

However, Donald Duck does not belong every 
place. If, for example, Lotus Corp. placed him on the 
title screen for 1-2-3™ or Symphony™, most users 
would have some serious doubts about the profes- 
sional quality of the program. 

On the other hand, a learning program for 
children might well use one or more cartoon 
characters to good advantage, to help keep the 
interest of the child and to turn the learning session 
into a game rather than a chore. 
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When designing the visual displays to be pro- 
duced by your programs, keep in mind both the 
nature of the program itself and the nature of the 
intended user audience. Make sure that each 
display is appropriate to both and that the intended 
user will have no trouble relating the display to the 
operation of the program. 


Sector 3: Plain or Fancy? 


How elaborate should your video displays be? 
Should you use high-density graphics? Multiple 
colors? Clever scrolling routines? Or should you 
skip all of that and stick with line drawings and 
blocks? How can you decide? 

One common problem with many different 
computers is the lack of a single video display 
standard. Even in a single computer, there can be 
substantial problems. For example, in the IBM PC 
and its compatibles, IBM originally provided two 
separate display interfaces. The monochrome 
interface was limited to a character generator ROM 
and could not handle graphics. The color interface 
had RGB outputs and could handle graphics as well 
as predefined characters. However, its character 
display memory was addressed differently than the 
monochrome display memory. This made it difficult, 
to say the least, to write a program that would 
handle either display according to the hardware 
configuration of the computer. 

Commodore has done a better job of maintaining 
compatibility between different types of computers, 
but the compatibility is still not absolute. Also, 
newer computers may require compromises to 
allow room for desired improvements. 
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Altogether, the newer display modes and capa- 
bilities will be non-existent in earlier computers, and 
possibly different in other models. Thus, if you are 
writing a program to be used on as many different 
machines as possible, you should be careful to stick 
with those display capabilities available on all 
versions of the computer. The C64 and C128 have a 
number of graphics characters available in the 
character generator ROM. You should use these if 
at all possible, since they have remained unhanged 
since the early Commodore PET, and will probably 
remain in all future compatible Commodore com- 
puters. 

All of the demonstration programs on all of your 
Program Disks have been deliberately limited to the 
graphics characters available from the keyboard 
and the character generator ROM, since these have 
not changed. This is why these programs can be run 
by a C64 or C128, the VIC 20, or even the old 
Commodore PET, if anyone still has a PET and has 
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disk drives for it. Whatever machine is in use, the 
displays will be the same. 

Of course, some applications require the use of 
bit-mapped graphics, multiple colors, or other 
special displays. In such a case, it is of course 
perfectly permissible to specify the precise hard- 
ware configuration that is required in order to run 
the program. However, again be careful. Do not 
specify some esoteric or little-used add-on card, 
unless it is truly necessary. To do so will make the 
program less useful to most people, not more useful. 

As a general rule, you can incorporate into your 
program any feaures or special requirements that it 
really needs in order to accomplish its task. How- 
ever, you should not insert requirements that the 
program does not really need. Try to make your 
program as widely useable as possible. 


Sector 4: Using Simple Sounds 


Sound effects and fancy noises may be appropriate 
to a few types of programs, but not really to very 
many. Nevertheless, some sounds are useful and 
helpful during the execution of a program. 
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For example, if your program calls for writing 
data to a disk in such a way that data on the disk may 
be destroyed, it makes sense to request confirma- 
tion of the user that the data is replacing other data 
as it is written. In such a case, a sharp b-e-e-e-e-p 
from the speaker can alert the user that loss of some 
data on the disk is imminent. Thus, confirmation of 
the command must occur before the computer will 
proceed. 

Or, if you specify that a file is to be saved and the 
computer finds a file of the same name, it may beep 
at you to make sure that you have the intended disk 
in the drive. 

In the Commodore 64 and 128, a built-in sound 
generator IC can be used to provide a wide range of 
sounds, or even music if appropriate. Simply 
program the SID to perform the required task. 

One possible application would be used where 
the user is keyboarding a lot of data. In such cases 
an audible “click” may be helpful as a response’ to 
each keystroke. 


Another application for tones is the case where 
you have set the computer to performing a time- 
consuming task that requires no user input or 
supervision. In such a case, you can write your 
program so that the computer will beep upon 
completion of the task. Depending on the circum- 
stances, you might want only a single beep, or you 
might want a repeated beep tone until the user 
comes back and presses a key. The repeated tone 
would be used in cases where a prompt user 
response is essential or at least important. 


Sector 5: Using Multiple Tones 


If your program is such that different warning. 
conditions may occur in any order, you may want to 
use different tones to indicate different situations. 
The duration of a tone can also be adjusted if 
desired. 

Since the Commodore computers have the 
three-channel SID built in, and each channel can 
produce sounds over a wide frequency range, it is 
not difficult to program the SID to produce any 
sounds desired. 

Note that in the Commodore computers, it is not 
possible to bypass the SID and drive the speaker 
directly. This is because the speaker is not built into 
the computer, but rather is part of your TV set or 
video monitor. This is not really a problem, since the 
SID is so easily programmed. However, you must 
remember to turn it off when you have completed 
the desired sound. 

As a general rule, sounds should be used for 
emphasis and to attract attention to a problem or 
possible error. You should avoid using sounds 
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during program data entry or normal usage. The 
reason for this is that excessive noises become an 
annoyance rather than a help. Also, do not use too 
many different sounds in one program. If you do, 
they will tend to be confusing rather than informa- 
tive. 


Sector 6: Music and Speech 


While the program should not distract the user while 
he or she is busy at the keyboard, there are often 
occasions when the user is actually idle, and waiting 
for the computer to complete a task. With the 
Commodore computers, disk access via the serial 
bus is a lengthy process, during which the computer 
may not seem to be doing anything. During such a 
time, you might wish to include an “entertainment” 
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routine in your program. Such a routine can “steal” 
a small amount of processor time to play some 
music appropriate to the program. At the same 
time, this lets the user know that the computer 
hasn’t glitched and either fallen asleep or gone ona 
trip to Mars or beyond. 

In another case, your program might be specifi- 
cally intended for entertainment. For example, you 
might program a birthday “card” or a similar 
program for some holiday. In such a case, the 
program could display your greeting message and 
picture on the screen, while it plays the appropriate 
music. (Of course, in this case you need not worry 
about matching everybody’s hardware, since you 
will already know what hardware the intended 
recipient has.) 

Speech is much more complex than music, but 
the basic techniques are very similar. There is a 
commercial program available called SAM, which is 
short for Software Automatic Mouth. We cannot 
include it with this module because of the cost, but 
we have tried it out. We find that the quality of 
speech it produces is surprisingly good for this type 
of hardware. 

Of course, as with music or individual sounds, 
computer-generated speech should be limited to 
those occasions when they are necessary, or when 
the operator will not be occupied. Computer speech 
is still in its infancy, and the quality is not exceptional 
in comparison with normal speech. As a result, full 
attention must be paid to it to understand it well. 
This prevents the operator from doing anything else 
while the computer is talking. 

Nevertheless, computer speech can enhance 
your programs considerably if used sparingly and in 
the proper circumstances. 
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PRACTICAL ALGORITHMS 


We took a few preliminary looks at algorithms in 
earlier modules. Now, however, we will look harder 
at what algorithms are, how they are used, when 
they are used, and why they are used. In addition, 
we will see anumber of practical algorithms, and see 
how they work. 


Sector 1: What is an Algorithm? 


Computers cannot perform complex mathematical 
operations. Indeed, acomputer is capable of 
performing only a very limited number of opera- 
tions. Specifically, a computer can use logic gates to 
perform the logical functions AND, OR, XOR, and 
NOT. Every other operation performed by the 
computer is based on these four logic functions. In 
fact, even the XOR (eXclusive OR) function can be 
constructed using the other three. 

Of course, some additional capabilities are built 
into the computer hardware. This permits the 
computer to perform addition and subtraction, 


MODULE 10 


logical and arithmetic shifts and rotates, and a 
variety of other functions. Newer microprocessors 
include multiply and divide instructions, the ability 
to locate data in many different but useful ways, and 
other enhanced capabilities. However, all of these 
capabilities are still based entirely on the basic logic 
functions we named above. 

Despite the advancing capabilities of micro- 
processors and computers in general, they still 
cannot perform all mathematical operations, nor 
can they reason or think for themselves. Rather, 
they can perform only the instructions listed in a 
program, that specifically define the operations to 
be performed and the order in which they are to be 
performed. 

But in order to be useful, the computer must be 
able to do at least some of these things. Since the 
capabilities are not built in, they must be pro- 
grammed instead. Each desired function or opera- 
tion must be programmed entirely in terms of 
operations that the computer already is able to 
perform. This is where algorithms come in. 
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An algorithm is a numerical procedure for solving 
a problem. It doesn’t matter what kind of problem it 
is; an algorithm can be designed to break it down 
into individual steps that the computer can perform. 

Algorithms are usually incorporated into pro- 
grams as subroutines or as external functions which 
may be called when needed. In that way, a single 
algorithm may be used many times to solve the 
same problem or equation, but using different initial 
data each time. 


Sector 2: Typical Applications for Algorithms 


Algorithms are used to handle any kind of data or 
information in ways that the computer cannot 
normally operate. For example, a computer deals 
specifically in integer binary numbers. Most micro- 
computers deal with these binary numbers in 
groups of 8 bits each. Because an 8-bit binary 
number is handled as a single parallel unit, and 
because it is a “bite-sized” unit of data, the 8-bit 
binary number is commonly known as byte. Some 
microprocessors are also able to operate on 16-bit 
words and 32-bit long words. 

Regardless of the number of bits that the micro- 
processor can handle at once, they still constitute a 
binary integer within the computer. The CPU 
cannot deal with any other kind of number. 

But if that’s so, how can BASIC handle real, 
floating-point numbers in the range of 1E-38 to 
IE+38? It accomplishes this by a process of repre- 
sentation. In Microsoft’s BASIC interpreters, 
floating-point numbers are represented as a 24-bit 
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mantissa and a 6-bit characteristic. You may 
recognize these terms from a discussion of loga- 
rithms. Here they have very similar meanings, 
except that they are expressed in binary, rather 
than decimal terms. The mantissa is always a 
number between 0.5 and 1. To find the actual 
number being represented, multiply the mantissa by 
the power of two indicated by the characteristic. 
Thus, the entire number is represented as a binary 
fraction times a power of two. The characteristic 
uses only 6 bits of the fourth byte. The remaining 
two bits indicate the signs of the mantissa and 
characteristic. 

Now that we have a way to represent real 
numbers in the computer using binary integers, we 
need ways to perform various mathematical com- 
putations using them and ways to translate back and 
forth between this representative form and dis- 
played decimal numbers. These functions are 
performed by algorithms. 

Mathematical functions are also performed using 
algorithms. For example, natural logarithms, expo- 
nentials, and trigonometric functions are all per- 
formed by algorithms which use only addition, 
subtraction, multiplication, and division to make the 
calculation. 

There are other operations that we want the 
computer to perform. For example, BASIC includes 
operations on character strings, which allow you to 
compare strings, combine strings, or isolate parts of 
strings. Most BASICs also allow you to scan a string 
for a matching segment to a shorter string. How is 
this possible when the CPU can only handle binary 
integers? 

We start by using a binary code to represent each 
character that we will use. Several such codes have 
been developed for various purposes, but most 
computers are standardized in this respect: they use 
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the American Standard Code for Information In- 
terchange (ASCII). This code uses seven bits to 
represent punctuation marks, digits, upper and 
lower case letters, anda set of 32 control codes. You 
are already familiar with these codes from earlier 
modules. For reference, they are repeated in Figure 
4-1, 

Now that we can represent characters as binary 
integers, we can tell the CPU to compare them, put 
them in a specified sequence, scan through them, 
etc. We can develop algorithms which will deter- 
mine the correct alphabetical or numeric sequence 
for the codes and rearrange them in the desired 
sequence (sorting). We can also develop algorithms 


for comparing and manipulating sequences of codes 
which represent words or large numbers. 


Sector 3: Some Practical Algorithms 


There are two basic classes of values that may be 
represented within a computers numeric and non- 
numeric. Numeric values are numbers in any 
desired form. Nonnumeric values are characters, 
strings, etc., which are not to be treated numeri- 
cally. Each type of representation has its own 
advantages and disadvantages with respect to the 
other. 


7-BIT ASCII CODE CHART 


ar on Sel ey 
fm fof for fer[o fe pe few fet fel a 


Se se hs a oh ee en 


Figure 4-1. The ASCIl codes. 
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Algorithms for mathematical functions are often 
based on the infinite series. In such a series, an 
infinite number of terms are added together to 
calculate the desired function. Of course, we want 
to be able to stop adding terms at some point, which 
means that we will never get the final answer. 
However, each term is smaller than the preceding 
term, so its effect on the final answer is smaller. 
Therefore, we can obtain any desired degree of 
precision just by determining how many terms we 
want to use. 

Most such calculations as implemented in com- 
puter programs are based on the MacLaurin series. 
This includes trigonometric functions, logarithmic 
functions, and exponential functions. In this appli- 
cation, we always use natural logarithms and 
exponentials (to the base e, where e = 2.71818...). 
For example, to find an exponential (e), we would 
devise an algorithm to find the sum: 


2 3 4 5 6 
x Xx xX xX xX 


oS gh se se ee Set 
2! 3! 4! 5! 6! 


This series would actually be difficult to imple- 
ment, because each term would have to be calcu- 
lated individually, and then added to the growing 
total. Calculating successive powers of any number 
takes time, and will take longer and longer as the 
power increases. Also, computing all of those 


factorials would be tedious and time consuming. We 
could provide the factorials as constants, since they 
are needed in other series as well. However, we also 
need the individual numbers as constants. There- 
fore, let’s see if we can factor the expression in such 
a way as to allow us to use just x and individual 
numbers. We can do this as follows: 


xX x xX x x 
e=iltx (+ +7. + + 1 —))))) 
2 3 4 5 6 


The interesting point about this arrangement of 
the equation is that we can implement it with a short 
series of identical operations, where the only thing 
that changes is the numerical value in the denomi- 
nator of the fraction. Furthermore, we can carry out 
our calculation to any desired number of terms just 
by choosing the first denominator. The series will 
always converge (approach a fixed final value), 
because eventually the denominator will be larger 
than x. Therefore, we can select the degree of 
precision we want by picking an initial denominator 
sufficiently greater than x so that the innermost 
term will be no larger than the greatest allowable 
error. Then the series may be calculated to any 
desired number of terms using the following algo- 
rithm: 


1. Select desired innermost term number (either 
fixed or variable), as initial denominator N. 

. Initialize accumulated value to 1. 

. Multiply by external exponent, x. 

. Divide by current denominator, N. 

Add 1 to the result. 

. Decrement denominator N by 1. 

. If N>0, go to Step 3. 

. Stop. Exponential has been calculated. 
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This calls for a basic sequence of multiply, divide, 
add, decrement, test, and conditionally repeat. If 
you use floating-point arithmetic, the number of 
terms required is fixed and is determined by the 
number of digits of precision you are using. If you 
must calculate the answer to within a specified 
magnitude of error, the number of terms will depend 
on the value of x. In either case, the required starting 
point is easily determined by the program, and the 
routine will repeat until the denominator reaches 0, 
at which point the answer has been calculated. 
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The same kind of approach may be used for any 
function that may be expressed as a converging 
series of terms. 

Other mathematical operations must be broken 
down into other kinds of procedures. For example, 
a common requirement is to find the integral of a 
function. This can be solved directly by an analog 
computer, but not by a digital computer. Therefore, 
we must find another way. 

To accomplish this, we note that the mathemat- 
ical integral of a function is graphically equivalent to 
finding the area of the space between the curve and 
the Xaxis. Therefore, weshould beableto 
accomplish the same thing in a piece-wise fashion. 
To see how, refer to Figure 4-2. 


AVA : 


Figure 4-2. Performing a piece-wise integration. 
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If we cut the curve into narrow slices, as shown in 
the figure, the change in altitude of the curve within 
any one slice will be small. The narrower the slice, 
the smaller the change in altitude of the curve. 
Therefore, we can determine the altitude of the 
center of each slice, multiply it by the width of that 
slice, an thus determine the area under the curve 
within that slice. Then we can add all of these areas 
together to obtain the total area under the curve or 
under any portion of interest to us. 

If we make all slices have the same width, we 
won't have to multiply until we have added all the 
altitudes together. In that case, our algorithmic 
procedure will look like this: 


1. Initialize sum to 0. 

2. Initialize X to starting point plus 1/2 the width 
of one slice. 

3. Calculate the altitude of the curve at this value of 
X. 

4. Add this altitude to the current sum. 

5. Add the width of one slice to the value of X. 

6. If we have not reached the end value of X, go to 
Step 3. 

7. Multiply the complete sum by the width of a 
single slice. 

8. Stop. The calculation is complete. 


You may be wondering why you would ever want 
to perform mathematical integrations. However, 
they are necessary in many applications. For 
example, a common requirement is to perform a 
frequency analysis of some signal. This means that 
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we must convert an ordinary function that varies 
with time (a time-domain function) into an equiva- 
lent function, but this time in terms of frequency (a 
frequency-domain function). This is normally done 
by a mathematical procedure known as the Fourier 
transform, which involves some very tedious inte- 
gration procedures. A number of algorithms have 
been developed to perform this task quickly and 
relatively easily. They are generally designated FFT, 
for Fast Fourier Transform. 

Other mathematical algorithms may be required 
in such applications as matrix algebra, statistical 
functions, and in computer-assisted design and 
analysis. 

Nonmathematical algorithms are used to deal 
with nonnumeric data. Such data are stored and 
manipulated as strings of one or more characters. 
Typical string operations are comparison, sorting, 
concatenation, reformatting, and changing repre- 
sentation. Some of these functions are simple and 
can be performed directly; others are more complex 
and are good subjects for algorithms. 

Since each character can be represented as a 
single byte in the computer’s memory, comparing 
characters is no more difficult than comparing 
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bytes. In addition, the ASCII code is so arranged 
that the letter codes, in numerical order, represent 
the characters in alphabetical order. Therefore, we 
can sort the character strings in alphabetical order 
simply by sorting the codes into numerical order. 

If you need to compare strings that are more than 
one character long, you need only compare them 
character by character until an inequality is found. 
In 6502 assembly language, this is done by placing 
the addresses of the two strings somewhere in the 
Zero Page. Then, start with Y=0, and use indirect 
addressing to load one character into the accumu- 
lator and compare it to the other. If the characters 
are the same, increment Y and repeat. This will 
work for strings not larger than 255 characters, 
which is one of the reasons that strings in the 
Commodore computers cannot be larger than this. 

Of course, in higher level languages you can 
simply perform the comparison directly, as in the 
case of the BASIC expression IF A$<B$ THEN---. 
Then it is up to the interpreter of compiler to set up 
and perform the comparison. 


One kind of string operation that can make good 
use of an algorithm is reformatting. For example, 
suppose you want to reformat a numerical string (all 
the characters are digits with a possible decimal 
point) to show commas and a dollar sign ($), so as to 
express the number as dollars or dollars and cents. 
The extra characters are not part of the number and 
will not normally be included when the number is 
converted to a numeric string. 

To reformat the string, the algorithm must first 
locate the decimal point (if any), and start from 
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either that point or from the rightmost end of the 
string. It must then scan the string to the left in 
groups of three digits each, and insert commas 
between groups of three digits. However, it must 
always place a valid digit to the left of each comma so 
we don’t begin the number with a comma. Then if a 
dollar sign or leading asterisks (*) are required, it 
must fill these in to the left of the significant digits. 

Two of the most important algorithms, however, 
are the ones that convert a character string to 
numeric format and a number to string format. 
These algorithms are normally used for numeric 
input and output. That is: the original numbers are 
input as character strings and are then converted to 
numeric format. All numeric manipulations and 
calculations are then performed and the results 
stored. Finally, the desired results are converted 
back to string representation for output. 

To convert a numeric string to numeric repre- 
sentation, we follow this procedure (assume decimal 
numbers — digits 0-9 — with possible sign and 
decimal point): 
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1. Initialize number to zero. 

2. If the first character is a ’-’ sign, save it. 

3. Starting from the left end, get this character. 

4. If character is a decimal point ’.” start counting 
remaining digits. 

5. If character is not a digit, exit to Step 10. 

6. Remove ASCII coding from present digit. 

7. Multiply partial number by 10. 

8. Add new digit to partial number. 

9. Go to Step 3. 

0. Retrieve number of digits following decimal 
point. 

11. Divide number by 10 raised to this power. 

12. If there was a leading ’-’ sign, negate final 

number. 
13. Stop. Number has been converted. 


Note that this algorithm can be applied to any 
desired base. In fact, the FORTH language does 
exactly this, except that it does not normally handle 
floating-point numbers. Therefore, in FORTH the 


decimal point is used merely to distinguish between 
single-precision (16-bit) and double-precision 
(32-bit) integers. However, the base used is con- 
tained in the variable BASE, and can literally be any 
desired value up to 32,767. Generally, only decimal, 
octal, and hexadecimal are used, but others are 
permitted for special applications. 

To convert a number back to string format, 
exactly the opposite procedure is used. Again, we 
will assume decimal numbers for this algorithm: 


1. Initialize output string to null. 

2. Determine sign of number. Save sign for later 

use. 

3. Take absolute value of number (make it 

positive). 

4. Determine power of ten that, when multiplied 
by number, will make number an integer with no 
trailing zeros. Save this power. 

. Multiply number by this power of ten. 

. If power was negative or zero, generate that 
many zeros into the string. 

7. Divide number by 10; save both remainder and 
quotient. 

8. Add ASCII coding to remainder; place charac- 
ter at left end of string. 

9. Decrement power of 10 saved in Step 4. If result 
is zero, place ’.’ character at left end of string. 

10. If quotient from step 7 is greater than zero, 

make it the new number and go to step 7. 

11 If initial sign was negative, place ’-’ at left end of 

string. 

12. Stop. String contains the number in ASCII 

format. 


no 


These two algorithms are based on the proce- 
dures for converting numbers from one base to 
another. They can be readily adjusted to handle 
input and output in floating point format (qn.- 
nnnnnEqxx), if desired. In that case, the first step is 
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to adjust the numeric value to a number between 1 
and 10, times an appropriate power of 10. In this 
case, the decimal point is always placed to the right 
of the first significant digit. Therefore, the algorithm 
must wait until the final quotient is less than 10 (or 
the base), and then put down the decimal point 
before placing the final digit at the left end of the 
string. The sign is handled as before. 


Sector 4: Successive Approximation 


In many cases, it is not possible to directly calculate 
the answer to a mathematical problem. This is 
especially true with very complex functions. In such 
cases, it is often easier to make a guess at the 
correct value, and then check and correct that 
guess. If this is done properly, it can rapidly reach 
the correct answer. 

One of the most effective algorithms to accom- 
plish this is called either Newton’s method or, 
alternately, the Newton-Raphson algorithm. This 
technique requires that the original problem be 
expressed as a function f for which the first 
derivative f’ may be found. For example, to find the 
square root of a number, x, we have: 


f(x) =x’ -N, where N is the number whose root we 
want, and 


f(x) = 2x 


Now, if x, is a guess at x, then a better guess will 
be: 
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= & 
f’ (x) 
x -N 
cae x o 
2x 
2x’ -x°+N 
2x 
x +N 
7 2x 


Each time you run through this calculation, 
replace x with your better guess, x,. This approach 
may be used for any function for which you can 
determine the first derivative, provided that N is 
valid (For example, you cannot take the square root 
of a negative number: in such a case, this formula 
will not converge to a single answer.). 

Algorithms can be devised to solve any mathe- 
matical problem and most nonmathematical ones. If 
you can set up a repetitive procedure to solve a 
problem, you can let the computer do the “donkey 
work” of cranking out the answer. 
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ARTIFICIAL INTELLIGENCE 


Artificial Intelligence has become the latest buzz- 
word in computer programming. The idea that a 
computer can be programmed in such a way as to 
seem to think for itself has been a dream among 
computer manufacturers, programmers, and users 
for many years. We are just beginning to make this 
fascinating concept work. 


Sector 1: What is Artificial Intelligence? 


Artificial Intelligence (often designated AI) refers to 
a mode of computer operation in which the com- 
puter gives the appearance of true thought. Thus, a 
program using the principles of Al will seem to mimic 
true human mentation processes, at least within its 
own limited range. 

Conventional computer programs perform pro- 
cessing functions that produce a substantial amount 
of output using a minimum of input data. Thus, as 
shown in Figure 5-1, the conventional program uses 
fixed processing procedures to expand a small 
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amount of input data into a large amount of output 
information. AI programs operate in just the oppo- 
site fashion. As with the human brain, they accept 
large amounts of data and seek relationships 
between them and knowledge that they already 
have. Then, as shown in Figure 5-2, they produce a 
few outputs. 


INPUT PROCESSING 


DATA FUNCTIONS 


Figure 5-1. The operation of a conventional computer 
program. 


Writing Advanced Programs 


Track 5 


Figure 5-2. An Al program accepts many inputs and 
produces a few outputs. 


Of course, we can write any number of programs 
that will operate in this way and still cannot be 
considered “intelligent.” If we are to tell the differ- 
ence, we must have some kind of test we can apply. 
Such a test was devised in the very early days of 
electronic digital computers by a British mathema- 
tician named Alan Turing. The Turing Test is still a 
classic, and is considered to be a reasonable and 
practical way to determine whether or nota 
program operates in an intelligent manner. 

To perform the test, a human operator, knowl- 
edgeable in the subject area to be handled by the 
program, is placed in a room with a remote terminal. 
The user does not initially know whether there is a 
computer or another knowledgeable human at the 
other end. If the user cannot tell, from the responses 


received on the remote terminal, who or what is at 
the other end, then the program is considered to be 
intelligent. 

AI programs are somewhat more difficult to 
implement than conventional programs. They con- 
sist largely of a massive data base, which operates as 
a library of facts and information, together with all of 
the relationships that exist between those facts. 
This is known as the knowledge base for this 
program. It is this knowledge base that the program 
will use to relate and classify user inputs. 

Once the knowledge base is in place, the user 
inputs all known and observed facts concerning a 
particular situation. For example, a doctor looking 
for the most likely cause of an illness would input all 
observed symptoms for a given patient. The Al 
program would then associate all symptoms with its 
knowledge base, and examine all existing relation- 
ships. If there is still some doubt (more than one 
possible diagnosis), the program would prompt for 
additional information to allow it to distinguish 
between possibilities. Eventually, all but one possi- 
bility would be eliminated, at which point the 
program would produce as its output the most likely 
cause of the illness. 

Thus, this program would take a large number of 
inputs (the symptoms), associate them with its 
knowledge base, and then produce a single output 
(the probable illness). It operates by narrowing 
down the choices until there is only one choice left. 


Sector 2: Implementing Al 


Most computer languages are procedure oriented. 
That is, they are designed in terms of operations and 
functions to be performed. For example, in BASIC, 
FORTRAN, and similar languages, all of the built-in 
commands and keywords define actions to be 
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performed (PRINT, GOTO, FOR, +, -, *, /, etc.) or 
calculations to be made (LOG, SIN, ABS, etc.) on 
variables or constants that are explicitly stated. 

However, Al requires a large knowledge base that 
consists not of procedures but of objects. There- 
fore, a procedure-oriented language is handicapped 
in implementing an Al application. What we want 
instead is an object-oriented language. 

FORTH can be used to implement such an 
approach, because the user can readily define new 
words to be used in any desired way. However, the 
core FORTH dictionary is still procedure oriented, 
which means that we would have to add a whole new 
operating system to the dictionary before we could 
add the actual application words. We would much 
rather have a language initially designed to be object 
oriented. 


In recent years, several such languages have been 
developed. Two of the best known are LISP and 
PROLOG, although a number of others also exist. 

Using PROLOG, the knowledge base is con- 
structed from a series of relational statements. For 
example, to state that a room has a door and a 
window, you might state: 


has( room, door ) 
has( room, window ) 


A given knowledge base will contain a large 
number of such statements showing relationships 
between many different objects (or ‘atoms’). It may 
be stored on disk as a data file, which can then be 
loaded by PROLOG with the command: 
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consult( ‘filename’ ). 


From then on, you can ask questions or seek 
information stored in that knowledge base. 

If there are multiple associations in the knowledge 
base, PROLOG will, on request, report them one by 
one, in order. 

LISP has been around longer than PROLOG, but 
has many similarities in structure and operation. It, 
too, operates on lists of objects and relationships 
between objects. However, the specific commands 
and requirements are of course somewhat different. 


Sector 3: Applications of AI 


Al is already being used in a wide variety of 
applications in many fields. A relatively simple 
application involves the new word processor de- 
vices, which are essentially dedicated micro- 
computers in their own right. These function 
basically as electronic typewriters, except that they 
contain a built-in dictionary listing tens of thousands 
of words. Each time a word is typed in, the computer 
checks it against the dictionary. If it cannot find a 
matching pattern, it immediately complains and 
waits for either the correct spelling or an assurance 
from the user that this spelling is correct. 

It is also possible for the computer to provide alist 
of probable correct spellings, or to make the 
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corrections itself. Additional enhancements include 
grammar checking, correct punctuation, and even 
correct hyphenation. 

Along the same line, there is a commercial 
database manager program named SAVVY PC. 
This program is actually written in FORTH as a 
dedicated application. It uses Al techniques to 
correct any spelling errors in input commands. It will 
also search for names or other data that either 
sounds like or is spelled in a similar fashion to the 
input. This is a very good example of Al in use, since 
the program not only matches patterns, but will also 
match partial patterns to other partial patterns. 

Another practical application for AI is voice 
recognition. We have already seen that the com- 
puter can be programmed to speak recognizable 
words, although the quality of speech often suffers. 
This depends basically on the method of voice 
production used. However, a much more difficult 
task is to program the computer to recognize 
human speech and to use speech rather than a 
keyboard as input. 

Some progress has already been made in recog- 
nizing a specific voice. With this method, the user 
first uses a program to convert spoken key words 
into patterns in the computer’s memory. Then, a 
second program can match those patterns to new 
spoken words, so the computer can recognize 
repetitions of those particular words. 

Unfortunately, this method is limited to the 
individual who originally recorded the spoken 
patterns, and even then requires that he or she 
speak the words in almost exactly the same way that 


they were originally recorded. Other voices will 
contain different frequency components, and will 
not be recognized. Even the same voice, if distorted 
by acold or flu, will not be recognized. 

However, there is hope. Analysis of many differ- 
ent voice patterns shows that relative frequency 
patterns for producing given phonemes (individual 
sound elements) are very similar, even though the 
center frequency of the voice may differ. Using the 
techniques of AI, we are learning to ignore the 
differences between different voices, and recognize 
the specific patterns that represent the actual 
spoken words. 

Along with computer speech and speech recog- 
nition, computer vision is also advancing. With 
computer vision, Al techniques must be used to 
recognize image patterns. Individual objects are 
distinguished according to relative distance, pat- 
terns of light and dark, and shape. Shape and 
distance are then used to determine what the object 
probably is. 

Robotics is also an advancing science, thanks in 
part to AI. The term robot simply means “worker,” 
and early robots were basically mechanical devices 
which could perform one and only one task. More 
modern robots, however, have many capabilities. 
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Inthe first place, modernrobots are now 
controlled by built-in microcomputers. These may 
be preprogrammed or, in many cases, connected to 
an external source of control signals. Whether or 
not a robot has a physical connection to its external 
controls, it may carry a wide range of sensors to 
allow it to monitor pressure, temperature, sounds, 
light, etc. A stand-alone robot can even be arranged 
to monitor its own battery voltage and to go plug 
itself in for a recharge when necessary. In the 
meantime, it can avoid objects in its way, keep from 
bumping into walls, avoid stairs, and “feel” its way to 
the correct location or action. 

Al techniques can be used to make robots more 
sophisticated and able to perform more critical 
tasks. They can also be used to allow a robot to 
perform independently to a certain extent. The field 
of robotics is just getting started. Combined with Al, 
who knows where it might lead? 


Sector 4: AI hardware 


Although Al is still in its infancy, many advances 
have been made both in software and in hardware. 
The software advances have been in new pro- 
gramming languages and techniques. However, this 
is not the end of the story. Computing hardware has 
also been produced that is optimized for Al appli- 
cations. 

For example, a number of companies have 
produced computers that are specifically optimized 
for LISP. That is, the internal machine code is LISP, 
rather than a more usual machine code. As a result, 
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no LISP compiler is required; the computer will run 
the LISP program directly at full speed. 

The LISP engine is characterized by a large 
memory capacity, substantial stack space, and 
special “tag words” which allow it to execute even 
very large LISP programs at high speed. 

However, LISP engines (sometimes called Al 
workstations) are also very expensive. They start at 
about $30,000 and rapidly increase in price. There- 
fore, this is not generally the most effective way to 
perform AI tasks. 

On the other hand, aconventional micro- 
computer, minicomputer, or even mainframe has its 
own limitations. Memory capacity is limited unless 
external mass storage is used. But external storage 
is slow, and the computer still can only do one thing 
at a time. Such a computer requires considerable 
time to search through a large knowledge base. 

Speeding up the computer helps, of course, but 
there are limits to this. What we would like to do 
instead is to search different parts of the knowledge 
base simultaneously. However, one CPU cannot do 
this. What can we do to accomplish this? 

What we can do is use multiple CPUs, all working 
simultaneously on different parts of the problem. 
This approach is known as parallel processing and is 
much closer to the way the human brain operates. 
The idea is that each processor can search a 
different part of the knowledge base for matching 
patterns, and each one will report any success. 

For example, in the human brain we have a 
number of different “operations centers” associated 
with different senses and activities. There is a center 
for hearing, another for speech, and yet another for 
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vision. We can simulate this by putting a separate 
processor in charge of each individual function. All 
of the processors would then be coordinated by a 
“master processor” which would dynamically assign 
tasks to and receive data from the others. 

One example of this is the use of a co-processor 
in a computer to perform specialized tasks. In the 
IBM PC and compatibles, the 8086 or 8088 is able to 
use the 8087 math co-processor in this manner. The 
8087 is tightly linked to the main CPU, and will 
perform the required mathematical operations as 
specified in the program. Similar co-processors are 
available for other CPUs as well. 

It is also possible to have multiple processors 
work together to performa single task. This 
requires a carefully written program and operating 
system. However, if properly done, two or more 
processors can work simultaneously on a single 
problem without interfering with each other and 
without having to wait for each other. Even relatively 
slow processors can combine capabilities this way 
to outperform faster single processors. 

A variant on parallel processing is distributed 
processing. In this arrangement, many computers, 
often at widely separated geographical locations, 
are communicating with each other and are working 
together in a cooperative manner to perform the 
required task. The required data may be stored 
redundantly at several different locations, and 
multiple communications links established between 
the various sites. If this is done correctly, even if one 
station should drop out of the link due to power 
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failure or damage, the remainder of the network can 
still carry on. 

The use of parallel or distributed processing is not 
limited to AI applications, but will enhance such 
operations as well as more “standard” applications. 


Sector 5: Analog Intelligence 


Digital computers do not have a corner on AI. One 
new approach is to model more closely the opera- 
tion of the human brain on a hardware level. Such a 
model makes use of the fact that a neuron in the 
brain receives a complex combination of stimulae. 
Some tell the neuron to “fire,” thus passing a signal 
along to the next neuron. Other stimulae inhibit the 
neuron, and keep it from firing. Thus, the neuron will 
either fire or not depending on the combination of 
signals and the strength of signals it receives. 

Now, if we use a comparator to generate an 
output signal of fixed amplitude, and if we use a 
resistive network to mix input signals from various 
sources at different strengths, we can simulate the 
operation of the brain, using one comparator per 
neuron. 

Of course, such circuits are very large and very 
simple compared to the actual brain, and consist of 
at most a few hundred simulated neurons. Never- 
theless, they exhibit some very interesting proper- 
ties. These properties include both short- and 
long-term memory, and fatigue! It seems that these 
analog models of the human brain matchits 
behavior to an unexpected degree. 

It is not our purpose to cover this type of circuit to 
any extent here, since such analog circuits cannot 
be effectively simulated through programming. 
However, if you are interested in Artificial Intelli- 
gence, you should be aware that this type of circuit 
exists in experimental form. You may wish to look 
further into this topic. 
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OPTIMIZING YOUR PROGRAM 


There are many trade-offs you can make when you 
are designing and coding your program and when 
you are correcting and updating it. Some of these 
choices lie in how you accomplish a given task within 
the program, while others are determined by how 
you code and enter the program into the computer. 

In earlier modules, we have mentioned some of 
the ways in which the execution efficiency of a 
program can be improved. However, if it takes you 
three weeks of effort to remove 3 seconds of total 
execution time, was it really worthwhile? Clearly, we 
want to be able to analyze a program quickly 
enough to determine whether or not to even try to 
optimize it any further. Also, we want to be able to 
make as many optimizing decisions as possible 
during the initial design and coding of the program. 
This will leave us less work to do later on. 

Different optimizing decisions can be made at 
different points in the development cycle. There- 
fore, let’s take a look at each stage and see what we 
can do to optimize program performance without 
taking too much time to accomplish it. 
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Sector 1: Initial Problem Definition, 


There is not very much you can do to optimize your 
program while you are defining the initial problem. 
After all, it is difficult to optimize a program that 
doesn’t even exist as yet. However, there are a few 
points that you can keep in mind to help you 
optimize your program later on. 

For example, even while you are stating the initial 
problem, you can take note of those elements of the 
problem that will give the most trouble. These will 
include complex mathematical operations, possible 
lengthy searches for specific data, and, in general, 
any operations which you know will not be easy to 
code into a computer language. 

As you recognize these potential trouble spots, 
you can put your problem statement into greater 
detail at once, rather than waiting until later. This 
will save time for you, since you already know that 
you will have to expand these problem descriptions. 
If you do it now, while you are thinking about it, you 
can probably do all or most of the expansion 
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necessary without needing to repeat your work 
later. 


Sector 2: Defining the Solution 


While you are defining the solution, you can make a 
number of decisions that will help you to optimize 
your overall programming task as well as the 
program itself. The primary decision to make is the 
choice of programming language. 

As you define the solution, you will gain a good 
idea of just how large the program will have to be. 
You will also have a clear idea of what kinds of 
operations will primarily be required within the 
program. This is just the information you need to 
select the most effective programming language for 
this particular application. 
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Assembly language is suitable for small programs 
and for routines which must be designed to run as 
fast as they possibly can. Longer programs should 
always be written in some high-level language, 
except possibly for calls to assembly-language 
routines at critical points. 

The reason for this is that mapping time and 
coding time are just as much part of program 
operation as is program execution time. It takes just 
as long to code a line of assembly language as to 
code a line of FORTRAN or PASCAL. The differ- 
ence is that there will be several times as many lines 
of assembly language code as there will be of any 
high-level language. 

If you are writing a program either for commercial 
purposes or for your company, this rapidly becomes 
important. The total cost of program development is 
figured according to the number of lines of program 
code. When you figure in salary, computer time, and 
the need for debugging, updating, documentation, 
etc., as well as initial program development, you can 
assess the total cost of writing the program at $1,000 
per line! It is very difficult to reduce this figure 
significantly, but it is all too easy to increase it by 
sloppy or ill considered programming practices. 

When you do select a language, of course you 
must make it one you have available. However, if 
you have a choice available, select a language that is 
geared towards the type of application you have. 
Avoid using a language that is ill suited for your 
requirements. For example, you would never use 
COBOL for an application requiring heavy mathe- 
maticalcalculations, nor would you want 
FORTRAN for a word processing application. 
Always choose a language whose characteristics 
and built-in functions and commands match your 
particular requirements. 

Once you have selected your language of choice, 
define your solution procedures in accordance with 
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the requirements of that language. This will prede- 
fine many of your mapping requirements and will 
allow you to look ahead even further as you proceed 
with your program design. 


Sector 3: Mapping the Solution, 


While mapping the solution, by whatever means you 
prefer, try to organize the solution sequence for as 
few program breaks as possible. Jumps and 
branches require both time and space in the 
computer. This is fine when they are needed, but 
wasteful when they are not. 

Minimize the number of decisions required in the 
program, and make each decision as informative as 
possible. This does not mean to make long stretches 
of parallel but exclusive code. Rather, such separate 
program segments should be as short and as few as 
possible. 

In addition, if you can find a way to calculate a 
result rather than set up a conditional program 
segment, this will normally be preferred. The 
conversion of a 4-bit binary number to hexadecimal 
ASCII code is a case in point. Even if a conditio- 
nally-executed program segment is required, try to 
use a Calculation rather than a comparison, if 
possible, ahead of the conditional instruction. 

Also, set up your map or chart in accordance with 
the requirements of your selected language. If you 
make your chart clear and concise and follow the 
structure required by the language, you will be able 
to translate the chart almost directly to program 
source code. 
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Sector 4: Coding the Program 


While coding the program, distinguish between 
code that will be executed only once or a very few 
times, and code that will be executed many times. It 
is not worthwhile to spend large amounts of time 
optimizing code that will not be executed often, 
since such optimization will have little effect on 
overall program execution time. Instead, concen- 
trate your attention on those portions of the code 
that will be executed most often. If you can simplify 
those portions of your code, the savings in execu- 
tion time will be more worthwhile. 

When considering which portions of code to 
concentrate on for optimization, also keep in mind 
the purpose of the code, and the timing require- 
ments that may go with it. For example, even if the 
most common action in your program is to wait for 
keyboard input from the user, there is little point in 
spending time to optimize the code. The computer 
will still be much faster than the user, so any such 
work will be largely wasted. 

Likewise, if you are writing a routine to transfer 
data to and from a disk drive, it must of course be 
fast enough to match the fixed disk data transfer 
rate. However, once you have achieved that re- 
quirement, stop. Further optimization will have no 
effect on the performance of the program. Similar 
logic holds for serial data communications with an 
external peripheral device. 
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By concentrating on those program segments 
where program performance can really benefit from 
optimization, you can make your efforts count to 
the greatest possible extent. 


Sector 5: Debugging 


When debugging your program, narrow down the 
problem area(s) as quickly as possible. The faster 
you find the location of the error, the faster you can 
fix the problem. 

To this end, try to find test procedures and data 
that will indicate, by the nature of the incorrect 
results they produce, how the error occurred. This 
will help to tell which block of code caused the 
problem. 

In some cases, it is possible to build self-test 
capabilities into your program. If you can do this, 
you can get the program to tell you where it is 
misbehaving. 

This type of program construction takes a little 
practice, but it is well worth learning, since it can 
drastically cut your debugging time. 


Sector 6: Documentation 


There is very little you can do to speed up the 
documentation process. However, by placing lavish 
comments in your source code as you write it, by 
organizing your manuals in a logical sequence, and 
by making your manuals clear and concise, you can 


avoid taking extra time writing the documents, and 
at the same time make it easier for you or anyone 
else to find any needed information. This makes it 
easier both to use the program initially and to 
correct and update it later on. 


Sector 7: Updating 


Before you can update a program, you must 
understand its operation in its current state. If you 
wrote the program recently, you already know how 
it works. However, if someone else wrote it, or if you 
wrote it months ago, you will need to familiarize 
yourself with its present operation before you can 
proceed. 

Once you are familiar with the operation of the 
program, you can modify or update it just as if you 
were initially debugging it. 

Throughout the entire process of program design 
and development, try to maintain a reasonable 
balance between program efficiency and your own 
time. The result will be a workable, satisfactory 
program that is available in good time. This will be 
far more valuable to you, your employer, and other 
users, than an absolutely perfect program that is six 
months late. 
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A FINAL WORD 


Since this is the final module in your Contemporary 
Programming and Software Design Series, we will 
present no new problems for solution. However, we 
will suggest some possibilities that you may wish to 
pursue on your own, either for your own use or just 
for practice. 


Sector 1: The PDSW Program 


In module 9, we did not discuss the PDSW program 
to any extent. However, we did promise to place 
that discussion here. We hope that by following our 
procedures and experiencing to some extent the 
same problems we experienced, you will find it 
easier to avoid or at least reduce such problems in 
your own programming efforts. 

The problems encountered in PDSW can be 
divided into several clear categories. For example, 
the first group of problems to be encountered were, 
as usual, syntax errors. For example, in Line 320 of 
PDSW.FAS, we define the address of the kernal 
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routine to open a file. This address is $FFCO. 
However, it is very easy to specify FFCO instead 
(the letter O instead of the number 0). They look 
similar on the screen and they are physically 
adjacent on the keyboard. Such a simple error can 
cause no end of trouble! 

Even the name given to this routine must be 
specified carefully. We cannot call it OPEN, because 
that is already a valid BASIC keyword. Therefore, 
we called it FOPEN instead, and FAS accepted this 
definition. The same requirement existed for 
FCLOSE in line 330. 

The second category involves logical and se- 
quencing errors in the program. Of course, we had 
the IBM version of PDSW to help us structure the 
overall program, and we did in fact follow that 
structure. However, there are other problems that 
can appear, simply because file handling is relatively 
complex in the Commodore computers. 

For example, in order to read the text file into 
memory, we must first use the SETNAM and 
SETLFS routines to define the file to be opened. 
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Then, we can actually open the file using FOPEN. 
Even then, however, we cannot actually read the 
data. The next step is to open a channel for this file 
on the serial bus, using the CHKIN routine. Only 
then can we use the CHRIN routine to read the file, 
one character at a time. If these routines are not all 
used, or are not called in the correct order, the file 
data cannot be successfully read into memory. 

Because it is quite possible for a text file to be 
both wide and long, we had to allow for more than 48 
lines of text to be printed out. However, with only 48 
lines per page, this requires that we read in the first 
48 lines of text, print them out in sideways format, 
and then read in more text. This process would 
continue until the entire file was printed. 

This being the case, what could be more rea- 
sonable than to open the file and check for errors, 
open the printer channel, and then simply alternate 
back and forth between them. We would have one 
output device and one input device, so there would 
be no conflict, right? 

Wrong! The Commodore operating system will 
not permit the serial bus to have two open channels 
ata time. Thus, we can use FOPEN to actually open 
both the file and the printer at the same time, but we 
must use the CLRCHN, CHKIN, and CHKOUT 
routines to close one channel and open another as 
we switch back and forth between input from the file 
and output to the printer. We need not close the file 
or the device, but we must close one channel before 
we can open another one. 

To accomplish this, we first opened the file 
(starting at Line 1280), and then the printer device 


(Line 1510 and following). If no errors occurred, we 
could proceed to the main body of the program, at 
Line 2030. Only at this point could we use CLRCHN 
and CHKIN to enable us to read from the file. Then, 
we used CLRCHN and CHKOUT to enable the 
printer, at RDDONE (Line 3023). 

A much more serious problem, and one which 
took longer to locate, was in the operation of the 
calls to the kernal routines. We obtained detailed 
information on the behavior and requirements of 
each of these routines from the Commodore 64 
Programmer’s Reference Guide, which is pub- 
lished by Commodore specifically for use by people 
who want to directly access all of the capabilities of 
the computer, without being limited to the BASIC 
language. 

One of these routines is FCLOSE, which is used 
to close a previously opened file or device. This 
particular routine uses the A register to indicate the 
logical file number, and requires no other input 
information. However, it nevertheless modifies both 
X and Y in operation. Therefore, it is necessary to 
either save the contents of X and Y, or else make 
sure that nothing important is in them at the time of 
the subroutine call. 

Meeting this requirement led to the insertion of 
lines 2525 and 2545 in the program. Until this was 
done, the program would output only one or two 
characters, but would output them time and time 
again. The reason: just following the cal] to 
FCLOSE, you will find instructions such as DEY, 
INX, CPX, etc. With both registers modified, we 
have no idea what will be in them. We only know 
that they are no longer relevant to the program. 


Another problem, this time a small one, was that 
a “garbage” character was produced at the end of 
each output line. We traced this down to the CR 
character itself. This character is not a normal 
printing character, and is not intended to be output 
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to the printer. However, it still is needed to mark the 
end of the line. The solution: add Line 3125, to 
convert the CR to a SPACE character for output to 
the printer. 

A very subtle but nasty problem led to the 
inclusion of Line 2325. Without this line, input text 
was always read into RAM at the same place. This 
meant that only one line of text existed in RAM at 
any one time. You will also note that lines 2130 - 2190 
are missing from the program. This is where an 
alternate code was placed to update the text pointer 
at the end of each line. However, this code did not 
work correctly, so it was removed and Line 2325 
was added instead. 

In general, you can locate the places where the 
program was patched or corrected by looking for 
irregular line numbers. With a very few exceptions, 
the original program was written with line numbers 
counting by 10. The main assembly loop was 
deliberately started at Line 1000, and the character 
bit table was started at Line 8000. Also, the error 
messages and I/O subroutines were given their own 
groups of line numbers. However, the main body of 
the program was initially numbered almost entirely 
continuously. 

It is our hope that, by understanding the prob- 
lems we faced in converting this program for use on 
the Commodore computers, you can more easily 
understand and recognize typical problems that you 
might experience when writing or converting pro- 
grams on your own. Remember, no one, not even 
the most experienced programmers, expect their 
programs to work correctly the first time, or every 
time. They actually spend more time debugging 
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existing programs then they do writing new code. 

Don’t allow this to discourage you from pro- 
gramming; remember that in baseball a batting 
average of .300 is considered outstanding, and that 
means the batter hits the ball only 30% of the time he 
gets up to bat. The same logic holds true for any 
human endeavor, including programming. We 
aren't perfect, but we can always try to improve 
what we are doing. 


Sector 2: Possible modifications to PDSW 


As we mentioned above, nothing and nobody is 
perfect, and that most definitely includes our PDSW 
program. For example, the sideways output char- 
acters are larger than they need to be for many 
applications. In addition, the character quality 
cannot be said to be very good. Surely there must be 
ways to improve the program from this point. 

One possibility you may wish to explore is to 
improve character quality. This can be done by 
increasing the dot density of the printer. For 
example, you might double the dot density and use 
twice as many graphics blocks per character. This 
will give you characters that are the same size, but 
are darker and “fuller.” 

Or, you might try doubling the dot density and 
leaving the character patterns alone. This will make 
each character half as tall, and will allow for twice as 
many character rows on the page (96 instead of 48). 
However, be careful if you try this — you will have 
room in memory for only 256 characters per line. In 
either case, you can get double density from 
Epson-compatible printers by changing the #$4B 
character in Line 7450 to #$4C instead. 

Another possibility for improved character qual- 
ity: print each character column as two passes with 
the printer, preferably at high dot density. However, 
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cause the printer to execute a minimum linefeed 
(either 1/144” or 1/216”) before the second pass. 
This will require an even larger character data table, 
but will give you double density both horizontally 
and vertically. This is the technique used to produce 
Near Letter Quality (NLQ) print from a dot-matrix 
printer. 

You might also consider expanding the data table 
to allow the use of graphics characters. These can 
be produced as easily as the normal ASCII char- 
acters, and will enable you to reproduce on your 
printer anything that can be displayed on the screen. 


Sector 3: The Program Disk 


Since this module deals more with general ideas 
than with specific procedures, your Program Disk 
for this module does not contain any “TRACK” 
programs. Instead, we have located a variety of 


programs that are either in the public domain or are 
being distributed as “Shareware,” and we have 
placed these on your disk. These programs illustrate 
some of the many kinds of programs that have been 
developed for use specifically on the Commodore 
computers. Because the range of programs avail- 
able is so vast, we cannot possibly fit it all on a single 
disk. Furthermore, there is also a vast amount of 
commercial software still available for the Commo- 
dore 64 and 128, which of course we cannot 
distribute. 

We encourage you to try out and use the 
programs provided on your disk. They provide 
examples of what other programmers have done 
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and how they have handled the problems of video 
display, disk I/O, and printer output, where appro- 
priate. After trying out a program, you may decide 
that you like a particular approach, or you may 
decide to adapt it to your own requirements. Or, 
you may find that an approach used in a program 
does not appeal to you, but you could think of ways 
to improve it. 

You should also examine the program code itself, 
to see how the programmer accomplished the 
various tasks performed by the program. Again, you 
may find something that is just what you have been 
looking for, or that you can readily adapt to fit your 
needs. Some of the code you see may be just 
enough to spark some ideas of your own. 

In any case, please feel free to use these programs 
in any way that will help you with your own 
programming, or with your own use of your 
computer. 


Sector 4: A Final Word 


Whether or not you try working further on PDSW 
or on any of the programs we have explored 
throughout this Series, we urge you to keep your 
hand in and practice programming in whatever 
language and field you prefer. As you continue to 
practice programming, you will find that the proce- 
dures become clearer and easier, and you will be 
able to discuss them meaningfully with others. 

Whether you intend to become a commercial 
programmer, or just want to be able to deal 
knowledgeably with programmers, practice makes 
perfect (or nearly perfect, at least!), and the more 
experience you gain in working with your computer, 
the more effective you will be in the programming 
field. 


HAPPY PROGRAMMING!! 
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